In a cooperating environment, a complex interdependent relationship exists between components and it difficult to determine the real consumer of resources. During a cooperation process, one component usually consumes resources on behalf of another component. FIG. 1 shows this case of a Rich Client Platform (RCP) in the prior art, the RCP being the core of the Lotus client. RCP is based on the OSGI specification which has the feature of frequent cooperation between different components. In this case, different accounting determinations should be made with different components' roles and runtime context. FIG. 1 shows a typical process flow of an HTTP request. When the “HTTP component” accepts a service request, it will assign the process to “Servlet Components 1-n” completely, which will call the “Utility Component” for a functional process. When the “HTTP component” accepts a request from the administrator to configure the related system, it will call the “Configuration Processor Component” for a functional process, which will in turn call the “XML Processor Component” or the “DB Processor Component” according to the different categories of the related configuration. Obviously, the “Utility Component” consumes resources on behalf of the Servlet. But the Servlet is responsible for its own consumption of resources. To analyze the resource consumption in such an environment, the known methods are inadequate.
So, it is necessary to find the real consumer of resources in this environment, which is very significant to make a clear analysis on the use case of resources in a cooperating environment; to make effective performance diagnosis; and, to recognize the primary consuming point. To understand the resource consumption of software components, which will help to make changes necessary to improve component design, runtime processing and security, some efforts related to resource accounting have been made. But they have defects that make them improper to solve the problem mentioned above. The existing methods do not consider the real consumer of resources between cooperating components, while simply focusing on a single component's resource consumption. It is impossible to make a sensible accounting determination in a cooperating environment without consideration of the relationships between components and without reflecting the conditions of components and the runtime environment. Therefore, it is hard to solve the above-mentioned problem based on the present methods.
Currently, two main units for resource accounting are classified: thread and isolate (an encapsulated Java program or application component that shares no status with others). It is difficult to map different kinds of components to these two units. Most component models are independent from thread and an interdependent relationship exists between different components. So a lack of support to the unit of the usual component makes present methods difficult to be used as a foundation.
Further, these methods are dependent on mechanical code instrumenting. They provide the definition of the interface and related implementations and insert them into codes, which is difficult to change under different environments. So, under this case, it is necessary to find a new method to solve the problem of the real consumer of resources and make an effective accounting.